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for controlling the distribution and use of digital works having a fee reporting 



(54) System 

mechanism 

(57) A fee accounting mechanism for reporting fees 
associated with the distribution and use of digital works. 
Usage rights and fees are attached to digital works. The 
usage rights define how the digital work may be used or 
further distributed. Usage fees are specified as part of 
a usage right. The digital works and their usage rights 
and fees are stored in repositories (201). The repositor- 



ies control access to the digital works. Upon determina- 
tion that the exercise of a usage right requires a fee, the 
repository generates a fee reporting transaction (302). 
Fee reporting is done to a credit server (301). The credit 
server collects the fee information and periodically 
transmits it to a billing clearinghouse (303). 
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Description 

capability to ,ac,aa.a the materials. Audio and video '°™™& ^™% r each accounled lo , delivery „, .ha male- 

„, time has lapaed. A technique used or wd,ks«or ibased -«^ B ;j^ U ^^ e S ed . Melhod a™, Apparatus 

5££E~^^"^"~>TZ%^^^* use. Th,s is araptoyad in 
Vat another sdherhe is to distribute software, bat which requires a key to_ enaae «s 

rrffiC^^^KSl- system and method ,d, centrdUing the use and 
ai6 'trrhSrl g ,y P-idas a systant and h,^ ^ 

aartaara^r^rr^ 

rSd? w *««,-^^^rrrrr^^-^«'«* 
~a==^^^ 

"^Z b and ChX accordahde with the invention wil, now be described, by way o, example. w«h rererenoe 
* ^^Z^SZ^^ instantiate o, the operation o, the carrentiy pralerrad embodiment o, 
' *" S£ sTsTS* diagram i„us,ra,in 9 the various repeal types and the ,epos«o* tranaaction ft* between 

,hem F ; 8 :e%7:S 



2 



EP 0 715 243 A1 



P Rgu e relt^d4b are examp.es of rendering systems as may be uti.ized in the currently preferred embodiment 
° f %% P u:e S 5 n !l.u7tr a ts n a contents file .ayout for a digital work as may be uti.ized in the currency preferred embodiment 
° f ^Fi^: 6 illu^ a contents fi.e .ayout for an indrvidua, digital work of the digita. work of Figure 5 as may be 

om "^:^%™^>* — - «-*• p ™ nt »«• h9h,s is used ,o i " os,ra,e ' s,,i:, ' 

•^STJZSSZSZ?** M c^ponen* c, a repeal as a. zed ta the cunamiy 

^^SISJSSU"- - * "- * ~ Pre,e " ed emBOdlmenl " 

men of the present invention. 
OVERVIEW 

A system lor controlling use and distribution of digita. works is disCosed. The present invention is directed to 
supping commercial transactions j^"*^^?^ to any work that nas been reduced to a digital repre- 

Herein the terms "digital work", "work and ^\^^ZT^d any accompanying interpreter (e.g. soft- 
ocn.nt.on. This would inc.ude any aud.o, video, text, "^^^^^e™ to a digital work comprised of a 
w».o) «hat may be required for recreat.ng the work. The Xe ^°T^ r ^.^ eTS Xo rig 9 hts granted to a recipient 
coUcctionof other digital^ 

o, a d.gita. work. Generally, ^^^J^^ 9 ^*^ satisfied before the right may be exercised, 
usage right may have one or more specrfed cond,t, ^^' cn ' m " demonstrates the basic operation of the present 
F.gure 1 is a high level flowchart om.tt.ng w» >** sbut wtnch de ^ tr f e then appropria t e 

nvenfon. Referring to Figure 1 , a creator creates a digital wd*. step . 1 01 The crea determination of 

usage rights and fees, attach them remains secure.y in Re- 

appropriate usage rights and fees w.ll depend on ^^^^^^ i a session initiation by another 
posnory 1 until a request for access .s received. The request ° r a J c J s be ^ S be described jn greater detai , 
repository. Here a Repository 2 initiates a ^^^^ terlspeZZpos^ones are trustworthy. As- 
below. this session initiation .ncludes steps wh.ch helps to insure tha ™ '~P~ p Dj m Work for a state d 
suming that a session can be estab.ished, Reposrtory 2 may ^^^^^ y of the digital work, 
purpose, step 104. The purpose may be, for example to pnrt tto ° » ™ the usage rights associated 

The purpose will correspond to a specific usage ^^^X^^^- The check o1 the US3ge 
with the digita. work to determ.ne ,f the access to the d.grta ^^g^^ request has been attached to 
rights essentially involves a f^^^f^^J^S J the access is denied, repository 1 terminates 
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2 step 107 Once the digital work has been transmitted to repository 2, repository 1 and 2 each ge "erasing infor- 
mation to the access which is transmitted to a credit sen/er, step 108. Such double b.ll.ng reporting .s done to >nsure 

aga ™ p u:™^ 

from Roure 2 the various repository types will serve different functions. It is fundamental that repos.tor.es will share 
a core s^of iunction'ity which win enable secure and trusted communications. Referring to F.gure 2, a repertory 
201 epresen the genera, instance of a repository. The repository 201 has two modes of operat.cn; a sen/er ^mode 
and aTeques ler U. When in the server mode, the repository will be receiving and processing access requests^ to 
H^t 8 . worte WhTn in the requester mode, the repository will be initiating requests to access digrtal works^ Reposrtory 
201 ts qeneram the sense that rts prima^ purpose is as an exchange medium for digrta, works. Dunng the course of 
opeifon the repository 201 may communicate with a plurality of other repositories, namely a ^- zat,0 " r 7 e P° S ^ 
Zll^gZosW 203 and master repository 204. Communication between repos.tor.es occurs ut.l.z.ng a re- 

POSi C— TcSfon^ 

repoSes and subjected to fees and usage rights conditions. An authorization may be requ.red by both repos.tor.es 

irates is described below with respect to the registration transaction. ^..^ „ lWv . h 

Figure 3 lustrates the reposrtory 201 coupled to a credit server 301. The cred,t server 301 .s a dare. .which 

c'elrfnghouse transactions 304. The clearinghouse transactions 304 enable a secure and encrypted transm.ss.on of 
information to the billing clearinghouse 303. 

RENDERING SYSTEMS 

A rendering system is generally defined as a system comprising a reposrtory and a rendering < ^d^tau^io 

This'design assures that all communication lines between printers and prin ting dev.ces .are 
Writer unless they are within a physically secure boundary. This design feature eliminates a potential "fault point 
thro^ 

function" device shce it may execute digital works (e.g. software programs) and display digita. works (e.g. a d.grtKed 
o^JT^VZl rendering device can be viewed as having its own repository, although on.y one physical 
ep^ry i 'neX. Referring to Figu're 4b, a computer system 410 has contained therein a Kepos- 
; SSSTtJ. dfsplay/execution repository 411 is coupled to display device, 41 2 and execut.on dev.ce 41 3jh dashed 
Sox surrounding the computer system 410 represents a security boundary within wh,ch ^""^J^^SS 
to be secure The display/execution reposrtory 411 is further coupled to a cred.t server 41 4 to report any fees to be 
billed or a eels to a d'igLl work and arepository 415 for accessing digital works stored there.n. 
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STRUCTUPF OF DIGITAL WORKS 



■ lcan£1 rinhts are attached directly to digital works. Thus, it is important to understand the structure of a digital work. 

iwmmwmm 

"TlhTcurrently preferred embodiment, the file information for a digital work is divded into two files: 

"TspecX^d^k is a "she..- d-b,ock. A shell d-b.ock adds no new content beyond the content of *s parts. 
A shei*S SSX used to add rights and fee information, typically by distributors of d.grtal works. 



the right code. 



£5 
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DIGITAL WORK STATE INFORMATION 


Property 


Value 


Use 




Number 


A counter of the number of copies of a work that are in use. Incremented when 
another copy is used; decremented when use is completed. 




Time-Units 


Indicator of the maximum number of time-units that a document can be loaned 

nut 


Loaner-Copy 


Boolean 


Indicator that the current work is a loaned out copy of an authorized digital work. 


Remaining-Time 


Time-Units 


Indicator of the remaining time of use on a metered document right. 


Document-Descr 


String 


A string containing various identifying information about a document. The exact 
format of this is not specified, but H can include information such as a publisher 
name, author name, ISBN number, and so on. 


Revenue-Owner 


RO-Descr 


A handle identifying a revenue owner for a digital work. This is used reporting 
usage fees. . 


Publication-Date 


Date-Descr 


The date that the digital work was published. 


History-list 


History-Rec 


A list of events recording the repostories and dates for operations that copy, 
transfer, backup, or restore a digital work. 



The approach for representing digtal works by separating description data from content assumes that parts of a 
,„c J TcoZZTs but takes no position on the actual representation of content. In particular, it is neutral to the question 
l ^S^SSSl representation may take an object oriented approach. It would be natural to represent conten as 

^ represented in the d-blocks. Such variations in the design of the represents are poss.ble and are viable 
^Mf.rnaiives but may introduce processing overhead, e.g. the interpretation of the objects. 

D^w^aTe stored in a repository as part of a hierarchical file system. Fo.ders (also termed directories and 
subSSSTeSi the digital works as we., as other folders. Digital works and folders in a folder i are ordered n 
I ip^beUcal order The digital works are typed to reflect how the files are used. Usage rights can be attached to folders 
^iSStoSJ itself is treated as a digital work. Access to the folder would then be handled in the same fash on as 
rtny^ne^^igrtsM work As will be described in more detail below, the contents of the folder are subject to ^®' r ° W ^Jj^j 
Moreover fit management rights may be attached to the folder which define how folder contents can be managed. 

ATTACHING I ISAGE RIGHTS TO A DIG ITAL WORK 

„ is fundamental to the present invention that the usage rights are treated as part of the digital work As the digital 
work sdistrSi the scope of the granted usage rights will remain the same or may be narrowed. For example when 
^1 wo k is transferred from a document server to a repository, the usage rights may include the right tc loan ^a 
cotv Z Predetermined period of time (called the original rights). When the reposrtory loans out a copy of the d.grtal 
S2 the i usage ?£L in the loaner copy (called the next set of rights) could be set to prohibit any further nghts to loan 
out the codv The basic idea is that one cannot grant more rights than they have. 

The Sachmentof usage rights into a digital work may occur in a variety of ways. If the usage rights will be the 
same for an enZ d igla Two*, they could be attached when the digital work is processed for deposit in the digital work 
TcZe In th case of a digital work having different usage rights for the various components, this can be done as the 
"g". work ts being created. An authoring too. or digita. work assembling too. could be utilized which P rov,des for an 

aU TS^l:~^dS S work is copied, transferred or .oaned, a "next set of rights" can be 
specified. The-next set of rights" will be attached to the digital work as it is transported. 

Resolving Conflicting Rights 

Because each part of a digital work may have its own usage rights, there will be instances where the rights ,of a 
■confalned part" are different from its parent or container part. As a result, conflict rules must be established to dictate 
whCand how a rStt may be exercised. The hierarchical structure of a digita. work facilitates the enforcement of such 
Tu'es a S would be as follows: a right for a part in a digital work is sanctioned if and only it -t is sanct.oned 
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(1) each of the respective parts must have the right, ana w y )enjent m|e access to 

^examp.eotap^^ 

11 , a root d-block 1101 has child d-blocks 1102-1 05 Jn this ca se^rotf d D p rr|nt ^ 

the chi.d d-blocks 1102-1 105 represent articles ^^T^^^^^^ root d-block 1101 and child 

work represented by root d-b.ock V m ^^S^^^^^ and 1105 haV6 been ***** ^ 

"^hV^^ 

Under the .enient rule, the result would be <«^™**» *' ™£ printed so long as the usage fee is paid, 
could be printed and the ^^J^^^^^P^^ -™ ™* WOU,d b ° — P lished ^ 

»SS=ES===s== 



RFPOSITORIES 



,„ , h e oeacnptfcn C r*» 2. . »as in0 = = s ^^^S^iSSi 
core set of services for the transmission of digrtal work ^ h .^ a "^ r s ^ if[er jn ^ uftimat e functions that they perform. 

number assirjned to the repository a. the '^^^^^^£Ld on a repository being in a 

action h r„nrtinnal embodiment The functional embodiment is typically software 

embodiment such as an Application Specific .ntejrate . ChouJ ™^ M , compromised . m ay cause 

The hardware embodiment of a repository will be J*^^^^ of a repository are described with 
the repository to be disabled. The bas.c means 1200, storage system 

reference to Figure 12. Refernng to F.gure 12, J repc^iton/ « W£ * £ is P compr ised of a processor element 1201 
1207, clock 1205 and external interface 1206. ^^^^o^ZJL^ transaction and usage rights 
and processor memory 1202. The P^ss.ng means 201 p ov, f^^^Zry such as decryption and/or 
transaction functions for the reposrtony. Vanous > » °ii performed by the processing means 1200. The 

decompression of digital works and transaction ^^^Z^^Z^ component. The processor memory 
processor element 1201 may be a mic ^* S ^ Memories (RAM). Such 

^sl^ 

tree storage 1203 will store the descnp^ 
; content. The description tree storage 1203 *°E*^^ e descriptor storage 1203 may be stored on 

s^dSsiS 

a high capacity storage such as an optical disk. 
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The clock 1205 is used to time-stamp various time based conditions lor usage rights or for metering usage fees 
whic^may be associated with the digital works. The clock 1205 will have an uninterruptible power 
SeryTorderto maintain the integrity of the time-stamps. The external interface means 1206 proves Tor the s^na, 
connect on to other repositories and to a credit server. The external interface means 1206 provides , to the exchange 
o^anl vi^h standard interfaces such as RS-232 or Persona. Computer Manufacturers Card lndust,y Association 
^PCMCIA] I standards, or FDDI. The external interface means 1206 may also provide network connectivity 
( functional embodiment of a repository is described with reference to Figure 13. Referring to Figure 13 he 
funcfena embodiment is comprised of an operating system 1301, core repository seivices 1302, usage t™-ctan 
handler 1X3, repository specific functions, 1304 and a user interface 1305. The operating 

t iTreposrtonr a^d would typically depend on the type of processor being used. The operating system 1 301 would 
a U provide the basic services for controlling and interfacing between the basic components of the rep°srto* 

ThTcore repository services 1302 comprise a set of functions required by each and every reposrtory. The core 
repository services 1 30* include the session initiation transactions which are defined in greater deta.l below This set 
ofse^Tces also includes a generic ticket agent which is used to "punch" a digital ticket and a generic futhorc*™ 
sew or processing authorization specifications. Digital tickets and authorizations are specific mechanisms for con- 
tromna the Ttribution and use of digital works and are described in more detail below. Note that coupled to the co e 
rSosCse^lces are a plurality of identification certificates 1306. The identification certifies 1306 are required to 

en The h u e sa^ 

for bilHnq fees based on access. The usage transactions supported will be different for each repository type. For ex- 
ample it may not be necessary for some repositories to handle access requests for digital works. 

P The repository specific functionality 1 304 comprises functionality that is unique to a repository For examp^ 
master repository has special functionality for issuing digital certificates and mainta.nmg encrypt.on keys. The repository 
specific functionality 1304 would include the user interface implementation for the repository. 

Repository Security Classes 

For some digital works the losses caused by any individual instance of unauthorized copying is ^significant j and 
the chief economic concern lies in assuring the convenience of access and Overhead billing. In such cases, simple 
and inSp^e handheld repositories and network-based workstations may be suitable repertories, even though the 

™T^^^Z^^L as a digital copy of a first run movie or a -rer bond^or stock 
certfficate woufd be of very high value so that it is prudent to employ caution and fairly elaborate secunty measures o 
ensure thaUhey are not copied or forged. A repository suable tor holding such a digital work could have elaborate 
measures for ensurinq physical integrity and for verifying authorization before use. 

Bylnan^l untersal protocol, all kinds of repositories can communicate with each other ,n principle. However 

creators ^ 

is h!gh enough. For this reason, document repositories have a ranking system for classes and levels of security. The 
security classes in the currently preferred embodiment are described in Table 2. 



REPOSITORY SECURITY LEVELS 


Level 


Description of Security 


0 


Open system.Document transmission is unencrypted. No digital certificate .s required for 'dent.ficaton , 
The security of the system depends most fy on user honesty, since only modest knowledge may be needed 
to circumvent the security measures. The repositery has no provisions for preventing unauthorized 
programsfromrunningandaccessingorcopyingfiles The system does not prevent the use of removable 
storage and does not encrypt stored files. . 


1 


Minimal security. Like the previous class except that stored files are minimally encrypted, mclud.ng ones 
on removable storage. _____ - 


2 


Basic security. Like the previous class except that special tools and knowledge are required to 
compromise the programming, the contents of the repository, or the state of the clock. All digital 
commZcations are encypted. A digftal certificate is provided as identification. Medium level encryption 
is used Repository identification number is unforgeable. 
I Continuation of the Table on the next page 
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TABLE 2 (continued) 



RE POSITORY SECURITY LEVELS 
Description of Security 



r sneral security Like the previous class plus the requirement of special tools are needed to compromise 
l^S^^^f^^B^VtwX modest encryption is used on all transm.ss.ons. Password 
orotectont required to use the local user interlace. The digital clock system cannot be reset wthout 
££rtrttoi No Zls would be stored on removable storage. When executing works as programs, ,t 
ru^hemTn the° owr address space and does not grve them direct access to any fi.e storage or other 
^m^ntlining'stem code or works. They can access works only through the transm.ss.on 
transaction protocol. 



Like the previous class except that high level encryption is used on all communications. Sensors are 
u ed rec'd attempts at physical and electronic tampering. After such .tampering, Jh. repos.tory w... 
perform other transactions until it has reported such tampering to a designated server. 



Like the previous class except that if the physical or digital attempts at tampering exceed some preset 
TeZ^ZZeLn the physical integrity of the repository or the integrity of dig.tal and cryptograph c 

bar^ 

of authentic^ to indicate that the physical system has been comprom.sed. It also erases the contents 
of designated documents. 



Like the previousclassexceptthatthe.repositorywi.lattempt wireless communication to report tampering 

and will empl oy noisy alarms. . 

xhic correspond to a very high level of security. This server would maintain constant 
^SSTS^^ ^ -porting transactions, sensor readings, and attempts to 
circumvent security. , . . ■ 



will evolve according to social situations and changes in technology. 
Repository User Interface 

A user interface is broadly defined as the mechanism by which a user interacts wrih a repository in orde. ^to invoke 

Wmmmmmm 

that a repository will provide. 
CREDIT SERVERS 
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or including ft in a newly created work. A key to these alternative charging models is to have a low overhead means 
of establishing fees and accounting for credit on these transactions. 

A credit server is a computational system that reliably authorizes and records these transacts so that ees are 
billed and paid The credit server reports fees to a billing clearinghouse. The billing clear.nghouse manages the financial 
t"ansact,ons as they occur. As a result, bills may be generated and accounts reconciled. Preferably, the credit server 
Tu^s ore the fee transactions and periodically communicate via a network w*h the billing clear.nghouse for recon- 
dhation in such an embodiment, communications wtth the billing clearinghouse would be encrypted for integnty and 
security reasons. In another embodiment, the credit server acts as a "debit card" where transactions occur ,n real- 

^ VcfedTs^erisToZised of memory, a processing means, a Cock, and interface means for coupling to a re- 
pository and a financial institution (e.g. a modem). The credit server will also need to have security and authen nation 
functionality. These elements are essentially the same elements as those of a repository Thus a angle d~ 
be both a repository and a credit server, provided that it has the appropriate process.ng elements for carrying out the 
corresponding functions and protocols. Typically, however, a credit server would be a cardsized system in the posses- 
ion of the owner of the credit. The credit server is coupled to a repository and would interact v,a financ.al transacts 
as ^describedTelow. Interactions with a financial institution may occur via protocols established by the financial .nst,- 
tutrons them^ej ^ embodjment Cfedjt sefVers associated with both the server and the repository report the 
financial transaction to the billing clearinghouse. For example, when a digital work is copied by one repos.to^ to another 
or a Te credit servers coupled to each of the repositories will report the transaction to the billing clearinghouse. This 
is desirable in that it insures that a transaction will be accounted for in the event of some break in ^ co ^ un, ^'°" 
between a credit server and the billing clearinghouse. However, some implementations may embody only a single 
credit server reporting the transaction to minimize transaction processing at the risk of losing some transacts. 

USAGE RIGHTS LANGUAGE 

The present invention uses statements in a high level "usage rights language" to define rights associated with 
digital works and their parts. Usage rights statements are interpreted by repositories and are used to determine what 
Transactions can be successfully carried out for a digital work and also to determine P a '" ameters ; 0 '^ 
For example, sentences in the language determine whether a given digital work can be cop.ed, when and how nt can 
be used and what fees (if any) are to be charged for that use. Once the usage rights statements are generated, they 
are encoded in a suitable torm for accessing during the processing of transactions. 

Defining usage rights in terms of a language in combination wrth the hierarchical ^presentation^ °^.ta. wo k 
enables the support of a wide variety of distribution and fee schemes. An example is the ability to attach multipe 
veSSs of V3K to a work. So a creator may attach a PRINT right to make 5 copies for $10.00 and a PR.N ngh Ac 
make unlimited copies for $100.00. A purchaser may then choose which option best fits his needs. Anothere^mpe 
is that rights and fees are additive. So in the case of a composite work, the rights and fees of each of the components 
works is used in determining the rights and fees for the work as a whole. 

The basic contents of a right are illustrated in Figure 14. Referring to Figure 14, a right 1450 has b transactional 
comment 145^ and a specifications component 1 452. A right 1450 has a label (e.g. COPY or PRINT) which mdicates 
the use or distribution privileges that are embodied by the right. The transactional component 1451 oon^pond. to a 
particular way in which a digital work may be used or distributed. The transactional component 1451 is typical ly em- 
bodied in software instructions in a repository which implement the use or distribution privileges for the nght. The 

or" designate various transaction related parameters. In the current* preferred embodiment these spe^cations 
Zo ude copy count 1453. Fees and Incentives 1454, Time 1455, Access and Security 1456 and Control 1457. Each 
of these specifications will be described in greater detail below with respect to the language grammar elements. 

The usage rights language is based on the grammar described below. A grammar is a convenient means for 
defining valid sequence of symbols for a language. In describing the grammar the notation a ble] is used to ^indicate 
distinct choices among alternatives. In this example, a sentence can have either an a , b or c It must include 
exacllv one of them The braces {} are used to indicate optional items. Note that brackets, bars and braces are used 
to describe the language of usage rights sentences but do not appear in actual sentences in the language 

In contrast parentheses are part of the usage rights language. Parentheses are used to group items together in 
lists. The notation (x ) is used to indicate a variable length list, that is, a list containing one or more items of type x. The 
notation (xf is used to indicate a variable number of lists containing x. 

Keywords in the grammar are words followed by colons. Keywords are a common and very special case ,n the 
language They are often used to indicate a single value, typically an identifier. In many cases, the keyword and the 
parameter are entirely optional. When a keyword is given, it often takes a single identrf.er as its value. In some cases. 
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them , mow -Render Code ■ - TPlav • (Player: Player-ID} I Print: {Printer: Printer-ID}]" lists a cat- 



copies are erased 
• Play 



A orocess of rendering or performing a digital work on some processor. This includes such things as playing 
digi^ movies P^ing digital music, playing a video game, running a computer program, or d.spiay.ng a 

. Pnnt Vr^Z lorUna medium that is not further protected by usage rights, such as printing on paper. 

the default is that no rights can be exercised when it is loaned out. 
• Copy Make a new copy of a work 
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which themselves are treated as digital works and whose contents may be "hidden" from a party seeking to determine 
the contents of a repository. 

• Backup To make a backup copy of a digital work as protection against media failure. 

• Restore To restore a backup copy of a digital work. 

• Delete To delete or erase a copy of a digital work. 

• Folder To create and name folders, and to move files and folders between folders. 

• Directory To hide a folder or its contents. 

Grammar element 1 507 "Derivative-Works-Code : [Extract I Embed I Edit {Process: Process-ID}] {Next-Copy- 
Rights : Next-Set-of Rights}" lists a category of rights involving the use of a digital work to create new works. 

• Extract To remove a portion of a work, for the purposes of creating a new work. 

• Embed To include a work in an existing work. 

. Edit To alter a digital work by copying, selecting and modifying portions of an extst.ng digrtal work. 

Grammar element 1508 -Configuration-Code: = Install I Uninstall" lists a category of rights for installing and 
uninstalhng software on a repository (typically a rendering repository.) This would typically occur for the installation of 
a new type of player within the rendering repository. 

• Install: To install new software on a repository. 

• Uninstall: To remove existing software from a repository. 

Grammar element 1509 "Next-Set-of-Rights : = {(Add: Set-Of-Rights)} {(Delete: Set-Of-Rights)} {(Replace: 
Set-Of-Rights)} {(Keep: Set-OI-Rights)}" defines how rights are carried forward for a copy of a digital work. If the 
Next SSSSJli no^ specified, the rights for the next copy are the same as those of the current copy. Otherwise, 
the se^of righte or the ne* copy can be specified. Versions of rights after Add: are added to the current se of rights. 
Rights att Delete: are deleted'™ the current set of rights. If or* right codes are listed after Delete: , then aH- versions 
of rights with those codes are deleted. Versions of rights after Replace: subsume all versions of rights of the same type 

" *„ Reml^RigMsts not specified, then there are no rights for the original after all Loan copies are loaned out 
If Remaininq-Riqhts is specified, then the Keep: token can be used to simplify the expression of what rights to keep 
oehfnd aS of right codes following keep means that all of the versions of those listed rights are kept in the remammg 
copy. This specification can be overridden by subsequent Delete: or Replace: specifications. 

Copy Count Specification 

For various transactions, it may be desirable to provide some limit as to the number of "copies' of the work which 
may be exercised simuKaneously for the right. For example, it may be desirable to limit the number of copies of a digital 
work that mav be loaned out at a time or viewed at a time. . 

sl™ element 1510 "Copy-Count : = (Copies: positive-integer I 0 I unlimited 
defines the number of "copies" of a work subject to the right . A copy count can be 0, a fixed number. ^m*£ ™° 
copy-count is associated with each right, as opposed to there being just a single copy-count for the digital work. The 
Copy-Count for a right is decremented each time that a right is exercised. When the Copy-Count equals zero, the right 
can no longer be exercised. If the Copy-Count is not specified, the default is one. 

Control Specification 

Rights and fees depend in general on rights granted by the creator as well as further restrictions imposed by later 
distributors. Control specifications deal with interactions between the creators and the, distributors governing the m- 
posUion of further restrictions and fees. For example, a distributor of a digital work may not want an end consumer of 
a dioital work to add fees or otherwise profit by commercially exploiting the purchased digital work. 

Smmar element 1511 "Control-Spec : I (Control: {Resectable I Unrestrictable} {Unchargeab e I Charge- 
able})" provides a condrtion to specify the effect of usage rights and fees of parents on the exerc.se of the right A 
diqita work is restrictable if higher level d-blocks can impose further restrictions (time specrf, cations and access spec- 
ScT) on the right. It is unrestrictable if no further restrictions can be imposed. The defaurt setting "re**** 
A righTis ^chargeable if no more fees can be imposed on the use of the right. It is chargeable if more fees can be 
imposed. The default is chargeable. 
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Time Specification 

It is often desirable to assign a start date or specify some duration as to when a right may be exercised. Grammar 
element 151 2 "Time-Spec : = ({Fixed-. nterval i Sliding-lnterva. I Meter-Time} Until: Expiration-Date)- provides for 
specmca ton of time condrtions on the exercise of a right. Rights may be granted for a specified t.me. D.f.erent kmds 
o^me specifications are appropriate for different kinds of rights. Some rights may be exercised dur.ng a fixed and 
treZer^t^L. Some rights may be exercised for an interval that starts the first time that the right , .nvoked 
bv some transaction Some rights may be exercised or are charged according to some kind o! metered lime, when 
may be spirt into Separate inters. For example, a right to view a picture for an hour might be split into six ten mmute 
viewinqs or four fifteen minute viewings or twenty three minute viewmgs. 

The terms "time" and "date" are used synonymously to refer to a moment in time. There are several k.nds of time 
soecificattons Each specification represents some limitation on the times over wh.ch the usage right applies The 
Expiration-Date specifies the moment at which the usage right ends. For example, if the Expiration-Date « Jan 
1995 Mhen the right ends at the first moment of 1995. If the Expiration-Date is spec.f.ed as 'forever*, then the rights 
are interpreted as continuing without end. If only an expiration date is given, then the right can be exercised as often 

"mr™ 

U ^^^:^^^^ : = .nterva,: Use-Duration" is used to define an indeterminate (or 
■open") start time. It sets limits on a continuous period of time over which the contents are access^The period starts 
on the access and ends after the duration has passed or the expiration date is reached, whichever comes first. 
For example.^ the right gives 10 hours of continuous access, the use-duration would begin when the first access was 

ma 1;^rU°me 0 nn 

is a measure of the time that the right is actually exercised. It differs from the Sliding-lnterval specrf.cat.on ,n that the 
fime Zx the digital work is in use need not be continuous. For example, if the rights guarantee three , days or access^ 
those days could be spread out over a month. With this specification, the rights can be exercised unt.l the meter t,me 
is exhausted or the expiration date is reached, whichever comes first. 

Remaining-Use: = Time-Unit 

Start-Time: = Time-Unit 

Use-Duration: = Time-Unit 

All of the time specifications include time-unit specifications in their ultimate instantiation. 
Security Class and Authorization Specification 

The present invention provides for various security mechanisms to be introduced into adistr ibution 
Gramma^ e,ement1 51 6 "Access-Spec : = ( { SC: Security-Class} {Authorization: ^ ho "^^Z^Z'Z'- 
thorization: Authorization-ID*} {Ticket: Ticket-ID})" provides a means for restr.ct.ng access and transm ss.on ^Ac 
ceZ specifications can speeffy a required security Cass for a repository to exercise a right or a required authonzat.on 

t6St T'he k^wo'rd 55 is used to spec«y a minimum security level for the repositories involved in the access, if "SC: 
• is not specified, the lowest security level is acceptable. 

The optiona -Authorization:" keyword is used to specify required authorizations on the same reposrtory as the 
work The optional "Other-Authorization:" keyword is used to specify required author.zat.ons on the other reposrtory 

" ^"optional ticket:" keyword specifies the identity of a ticket required for the transaction. Atransactior .involving 
digital ficSts must locate an appropriate digital ticket agent who can "punch" or otherwise validate the ticket before 
the transaction can proceed. Tickets are described in greater detail below. 

in a transaction invoking a repository and a document server, some usage rights may require that he reposrtory 
have a particular authorization, that the server have some authorization, or that both repositor.es have (possibly drf- 
^eZxV^ZLs. Authorizations themselves are digital works (hereinafter referred to as an authorization objec ) 
S can be moved between repositories in the same manner as other digital works. Their copying and tnmrtff«g» 
subject to the same rights and fees as other digital works. A repository is said to have an author.zat.on rt that author- 
ization object is contained within the repository. «,„„„ii„,», 

in some cases, an authorization may be required from a source other than the document ^<"*"£»*« 
An authorization object referenced by an Authorization-ID can contain digital address information to ber used to se up 
rcommunications nk between a repository and the authorization source. These are analogous to phone numbers 
Fo suT access tests, the communication would need to be established and authorizat.on obtained before the right 
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could o b r e o e n X e e t r ^ sage r|ghts a varjant on thjs scheme js t0 nave a d j g i t al ticket. A ticket is presented to a digital ticket 
aaent whose type is specified on the ticket. In the simplest case, a certified generic ticket agent, available on all 
repositories is available to "punch" the ticket. In other cases, the ticket may contain addressing information for locating 
a "special" ticket agent. Once a ticket has been punched, it cannot be used again for the same kind of transaction 
(unless it is unpunched or refreshed in the manner described below.) Punching includes marking the ticket with a 
timestamp of the date and time it was used. Tickets are digital works and can be copied or transferred between repos- 
itories according to their usage rights. 

In the currently preferred embodiment, a "punched" ticket becomes "unpunched" or "refreshed when it is copied 
or extracted The Copy and Extract operations save the date and time as a property of the digital ticket. When a ticket 
agent is given a ticket, it can simply check whether the digital copy was made after the last time that it was punched. 
Of course, the digital ticket must have the copy or extract usage rights attached thereto. 

The capability to unpunch a ticket is inportant in the following cases: 

. A digital work is circulated at low cost with a limitation that it can be used only once. 

. A digital work is circulated with a ticket that can be used once to give discounts on purchases of other works. 
. A digital work is circulated with a ticket (included in the purchase price and possibly embedded in the work) that 
can be used for a future upgrade. 

In each of these cases, if a paid copy is made of the digital work (including the ticket) the new owner would expect 
to get a fresh (unpunched) ticket, whether the copy seller has used the work or not. In contrast, loaning a work or simply 
transferring it to another repository should not revitalize the ticket. 

Usage Fees and Incentives Specification 

The billinq for use of a digital work is fundamental to a commercial distribution system. Grammar Element 1517 
"Fee-Spec: = {Scheduled-Discount} Regular-Fee-Spec I Scheduled-Fee-Spec I Markup-Spec" provides a range 
of options for billing for the use of digital works. 

A key feature of this approach is the development of low-overhead billing for transactions in potentially small 
amounts Thus it becomes feasible to collect fees of only a few cents each for thousands of transactions. 

The grammar differentiates between uses where the charge is per use from those where it is metered by the time 
unit. Transactions can support fees that the user pays tor using a digital work as well as incentives paid by the right 
arantor to users to induce them to use or distribute the digital work. 

The optional scheduled discount refers to the rest of the fee specification-discounting it by a percentage over 
lime If it is not specified, then there is no scheduled discount. Regular fee specifications are constant over time. 
Scheduled fee specifications give a schedule of dates over which the fee specifications change. Markup specifications 
are used in d-blocks for adding a percentage to the fees already being charged. 

Grammar Element 1 51 8 "Scheduled-Discount: = (Scheduled-Discount: (Time-Spec Percentage)*) A Sched- 
uled-Discount is a essentially a scheduled modifier of any other fee specification for this version of the right of the 
diaital work (It does not refer to children or parent digital works or to other versions of r.ghts.). It ts a list of pairs of 
times and percentages. The most recent time in the list that has not yet passed at the time of the transaction is the 
one in effect. The percentage gives the discount percentage. For example, the number 10 refers to a 10 A discount 

Grammar Element 1519 "Regular-Fee-Spec : =({Fee: I Incentive: } [Per-Use-Spec I Metered-Rate-Spec I Best- 
Price-Spec I Call-For-Price-Spec] {Min: Money-Unit Per: Time-Spec>{M a x: Money-Unit Per: Time-Spec} To: 
Account-ID)" provides for several kinds of fee specifications. 

Fees are paid by the copy-owner/user to the revenue-owner if Fee: is specified. Incentives are paid by the revenue- 
owner to the user if Incentive: is specified. If the Min: specification is given, then there is a minimum fee to be charged 
per time-spec unit for its use. If the Max: specification is given, then there is a maximum fee to be charged per time- 
spec for its use. When Fee: is specified, Account-ID identifies the account to which the fee is to be paid. When Incentive: 
is specified, Account-ID identifies the account from which the fee is to be paid. 

Grammar element 1520 "Per-Use-Spec: = Per-Use: Money-unit" defines a simple fee to be paid every time the 
riaht is exercised, regardless of how much time the transaction takes. 

Grammar element 1521 "Metered-Rate-Spec := Metered: Money-Unit Per: Time-Spec" defines a metered-rate 
fee paid according to how long the right is exercised. Thus, the time it takes to complete the transaction determines 

Grammar element 1522 "Best-Price-Spec := Best-Price: Money-unit Max: Money-unit" is used to specify a 
best-price that is determined when the account is settled. This specification is to accommodate special deals, rebates 
and pricing that depends on information that is not available to the repository. All fee specifications can be combined 
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Grammar element 1523 Call-For-Price &pec . - uan r reau i re s a communication with a 

5LtT« Thle's sin*, ,o btf mora genera, ,han ft. scheduled d,.coun.. It . more 

c Jnenf d-block. This might be a convenient specification for use in taxes, or n d,str.butor overhead. 

RFPOSITOPV TRANSACTIONS 

o^ Qee to =■ riinital work the reDository will initiate various transactions. The combination 

r '~Em~^ 

nnnsact.ons, Sess.on In maton I ansa vajjd js establjsnedi transac t,ons 

wmmm 

"- specifying and implementing reposttories and thus form the need for vanous transacts. 
Message Transmission 

™ » Z«rZ *T« security class are encrypted uliiizing a public key enerypl.on 
SH9< ! .u fcfl .ommnnication can onlv be read (to a high probability) by the receiving repository, which holds the 



described below. 



15 



EP 0 715 243 A1 



Session Initiation Transactions 

A usage transaction is carried out in a session between repositories. For usage transactions involving more than 
one reposrtory or for financial transactions between a repository and a credit server, a registration transaction .6 per- 
Tmed A second transaction termed a login transaction, may also be needed to initiate the sess,on. The goal of the 
egTstratbn transaction is to establish a secure channel between two repositories who know each others ktamte. As 
! is assumed that the communication channel between the repositories is reliable but not secure, there .s a nsk that 
a non-repository may mimic the protocol in order to gain illegitimate access to a reposrtory. tho ct( ,n< 

?he registration transaction between two repositories is described with respect to Figures 16 and 17. The steps 
described are from the perspective of a Veposriory-I ■ registering its identity wrth a "reposrtory-2-. The reg.strat.on must 
be symmetrical so the same set of steps will be repeated for repository-2 registenng rts .dentrty w.th reposrtory-1. 
Ref e rng to Hgure 16, repository-1 first generates an encrypted registration identifier, step 1601 and then generates 
aTeqistration message, step 1602. A registration message is comprised of an identifier of a master reposrtory the 
^m^ZZiJe for the reposrtory-? and an encrypted random registration identifier. The identrficafon certrf.cate 
s encrypted by the master reposrtory in its private key and attests to the fact that the reposrtory (here reposrtory-1 ) s 
a bona f kie reposrtory. The identification certificate also contains a public key for the reposrtory, the reposrtory secur.ty 
fevel and a timestamp (indicating a time after which the certificate is no longer valid.} The registration .dentrfier .s a 
number generated by the repository for this region. The registration identifier is unique to he sess.on and .s 
encrypted in repository-1 's private key. The registration identifier is used to improve securrty of authent.cat.on by de- 
fect^ certain Ls ofcommunications based attacks. Repository-1 then transmits the registrafon message to repos- 

"^u'potreceTng the registration message, repository-2 determines if it has the needed public key tor the -aster 
repository, step 1604. If repository-2 does not have the needed public key to decrypt the ,dentrficat.on certrficate, the 

mni«;tration transaction terminates in an error, step 1618. 

9 Ass ming that repository-2 has the proper public key the identification certrficate is decrypted, step 160* Repos- 
itory-2 saves the encrypted registration identifier, step 1606, and extracts the reposrtory 

extracted repository identifier is checked against a -hotlist" of compromised document repositories, s ep .1608. In the 
cur ently preferred embodiment, each repository will contain "hotlists" of compromised repositories. If therepos tory 
is on the -hotlisf, the registration transaction terminates in an error per step 1618. Reposrtor.es can be removed from 

he ho^t when heir certificates expire, so that the list does not need to grow without bound. Also, by keeping a short 

stof SisTcertrticates that tt has previously receded, a reposrtory can avoid 

list These lists would be encrypted by a master repository. A minor var.at.on on the approach to improve efficiency 
wou d I have the reposttories first exchange lists of names of hotlist certificates, ultimately exchangmg only those Hsts 
Thanhey had not previously received. The "hotlists" are maintained and distributed by Master repos.tor.es. 

Note that rather than terminating in error, the transaction could request that another reg.strat.on message be serU 
based on an identification certificate created by another master repository. This may be repeated until a sat.sfactory 
identification certificate is found, or it is determined that trust cannot be estabhshed. 

Assuming that the reposrtory is not on the hotlist, the reposrtory identified needs to be verrfted. In other words^ 
repostory-2 needs to validate that the repository on the other end is really repository-1 . Th.s .s termed performance 
Sg and is performed in order to avoid invalid access to the repository via a counterfeit repository replay.ng are- 
corlg ofaprior session inrtiation between reposrto 

Tgenerating a performance message, step 1609. The performance message cons.sts of a nonce, the names o [ the 
respectrve repositories, the time and the registration identifier received from reposrtory-1. A nonce .s a generated 
message based on some random and variable information (e.g. the time or the temperature.) The nonce - n used to 
Teck whether reposrtory-1 can actually exhibit correct encrypting of a message using the pr.vate keys ,t claims to 
have o^a message that* has never seen before. The performance message is encrypted using the pubhc key .speeded 
in the SatiS message of repository-1 . The performance message is transmitted to reposrtory-1 . step 1 610. where 
ft is dec jp 2^ "pository-1 using its private key. step 1611 . Repository-1 then checks to make sure that the names 
^ZCZttE are correct.step 1612. that the time is accurate, step 1613 and that the registrator, den. er 
co responds to the one rt sent, step 1614. If any of these tests fails, the transaction .s temmnatec I per step 1616. 
Assumingtha ^^he tests are passed, repository-1 transmits the nonce to repository-2 in the clear, step 6 5. Reposrt 
2th™Xaes the receded nonce tothe original nonce, step 1617 Jf they 

fermTnateTin an error per step 1618. If they are the same, the registration transaction has successfully completed 

Tt this point, assuming that the transaction has not terminated, the repositories exchange messages conta n ng 
session keys to be used in all communications during the session and synchronize the.r clocks. Rgure 17 Ulustrates 
^^M^rton exchange and Cock synchronization steps (again from the perspective of reposrtory-1.) Re- 
erring to RgureT?, repository-1 creates a session key pair, step 1701. A first key is kept private and is used by 
ZS^1 to encrypt messages. The second key is a public key used by repository-2 to decrypt messages. The 
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second key is encrypted using the public key of repositoiy-2, step 1702 and is sent to repository-2, step 1703. Upon 
receipt repository-2 decrypts the second key, step 1704. The second key is used to decrypt messages in subsequent 
communications. When each repository has completed this step, they are both convinced that the other repository is 
bona fide and that they are communicating with the original. Each repository has given the other a key to be used in 
decrypting turther communications during the session. Since that key is itself transmitted in the public key of the re- 
ceiving repository only it will be able to decrypt the key which is used to decrypt subsequent messages. 

After the session information is exchanged, the repositories must synchronize their clocks Clock synchronization 
is used by the repositories to establish an agreed upon lime base for the financial records of their mutual transactions. 
Referring back to Figure 17, repository-2 initiates clock synchronization by generating a time stamp exchange message, 
step 1705 and transmits it to repository- 1 , step 1706. Upon receipt, repository-1 generates its own time stamp mes- 
sage step 1707 and transmits it back to repository-2, step 1708. Repository-2 notes the current time, step 1709 and 
stores the time received from repository-1 , step 1 71 0. The current time is compared to the time received from repository- 
1 step 1711 The difference is then checked to see if it exceeds a predetermined tolerance (e.g. one minute), step 
1712 If it does reposrtory-2 terminates the transaction as this may indicate tampering with the repository, slep 171 3. 
If not repository-2 computes an adjusted time delta, step 1714. The adjusted time delta is the difference between the 
clock time of repository-2 and the average of the times from repository-1 and repository-2. 

To achieve greater accuracy, repository-2 can request the time again up to a fixed number of limes (e.g. five times), 
repeat the clock synchronization steps, and average the results. 

A second sessbn initiation transaction is a Login transaction. The Login transaction is used tocheckthe authenticity 
of a user requesting a transaction. A Login transaction is particularly prudent lor the authorization of financial transac- 
tions that will be charged to a credit server. The Login transaction involves an interaction between the user at a user 
interface and the credit server associated with a repository. The information exchanged here is a login string supplied 
by the repository/credit server to identify itself to the user, and a Personal Identification Number (PIN) provided by the 
user to identify himself to the credit server. In the event that the user is accessing a credit server on a repository different 
from the one on which the user interface resides, exchange of the information would be encrypted using the public and 
private keys of the respective repositories. 

Billing Transactions 

Billing Transactions are concerned with monetary transactions with a credit server. Billing Transactions are carried 
out when all other conditions are satisfied and a usage fee is required for granting the request. For the most part, billing 
transactions are well understood in the state of the art. These transactions are between a repository and a credit server, 
or between a credit server and a billing clearinghouse. Briefly, the required transactions include the following: 

. Registration and LOG IN transactions by which the repository and user establish their bona fides to a credit server. 
These transactions would be entirely internal in cases where the repository and credit server are implemented as 
a single system. 

. Registration and LOG IN transactions, by which a credit server establishes its bona fides to a billing clearinghouse. 

. An Assign-fee transaction to assign a charge. The information in this transaction would include a transaction iden- 
tifier, the identities of the repositories in the transaction, and a list of charges from the parts of the digital work. If 
there has been any unusual event in the transaction such as an interruption of communications, that information 
is included as well. 

. A Begin-charges transaction to assign a charge. This transaction is much the same as an assign-fee transaction 
except that it is used for metered use. It includes the same information as the assign-fee transaction as well as 
the usage fee information. The credit-server is then responsible for running a clock. 

. An End-charges transaction to end a charge for metered use. (In a variation on this approach, the repositories 
would exchange periodic charge information for each block of time.) 

. A report-charges transaction between a personal credit server and a billing clearinghouse. This transaction is 
invoked at least once per billing period. It is used to pass along information about charges. On debit and credit 
cards, this transaction would also be used to update balance information and credit limits as needed. 

All billing transactions are given a transaction ID and are reported to the credit severs by both the server and the 
client. This reduces possible loss of billing information if one of the parties to a transaction loses a banking card and 
provides a check against tampering with the system. 

Usage Transactions 

After the session initiation transactions have been completed, the usage request may then be processed. To sim- 
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plify the description of the steps carried out in processing a usage request, the term requester .s used to refer to a 
the requester mode which is initiating a request, and the term server is used to refer to a repertory n he 
ervt mode and which contains the desired digital work. In many cases such as requests to pnnt or v.ew a work the 
request servermay be the samedevice and the transactions described in the fo..ow,ng ^ 
in such instances, certain transaction steps, such as the registration transaction, need not be performed. 

There are some common steps that are part of the semantics of all of the usage rights transactions. These steps 
are reared to as the common transaction steps. There are two sets -the "opening" steps and the closing' steps. For 
simS these are listed here rather than repeating them in the descriptions of all of the usage rights transactions. 

Trlsactions can refer to a part of a digital work, a comp.ete digital work, or a Digital work containing other digital 
works A.mough not described in detail herein, a transaction may even refer to a folder comprised of a plurality of digital 
works' The term "work" is used to refer to what ever portion or set of digital works is being accessed. 

Many of the steps here invoke determining if certain conditions are satisfied. Recall that each usage nght may 
have one or more conditions which must be satisfied before the right can be exercised. Digital works have parts and 
parts have parts. Different parts can have different rights and fees. Thus, it is necessary to verify that the -qu-rements 
afe met for ALL of the parts that are invoK/ed in a transaction For brevity, when reference .s made to checking whether 
fhe rTghts exist and conditions for exercising are satisfied, it is meant that all such checking takes place for each of the 

Rgure^ ^tratTJthe initial common opening and closing steps for a transaction. At this point it .assumed that 
,ca.s.ration has occurred and that a "trusted" session is in place. General tests are tests on usage rights associated 

To requirements imposed on the work as a consequence of its being on the particular repository as opposed tc > be,ng 
inched to the work itself. Referring to Figure 1 8, prior to initiating a usage transaction, the requester pertor ms any 
general tests that are required before the right associated with the transaction can be exercised, step, 180T For ex- 
Ip'e install, uninstall and delete rights may be implemented to require that a requester have an author.zat.on , cert, I- 
rTo before the right can be exercised. Another example is the requirement that a digital ticket be present and punched 
bc ore a digital work may be copied to a requester. If any of the genera, tests fail, the transaction ,s not ,n,t ated step, 
-02 Assuming that such required tests are passed, upon receiving the usage request, the server generates a trans- 
Kh* Identifier that is used in records or reports of the transaction, step 1803. The server then checks whether the 
S3 "Zn granted the right corresponding to the requested transaction, step 1804. ,f the dtftt work has 
not been granted the right corresponding to the request, the transaction terminates, step 1805. If the d.grtal work has 
Zon granted the requested right, the server then determines if the various conditions for exercs.ng the right are 
Z Jt Time basse Conditions are examined, step 1 806. These conditions are checked by examining the time ap£ 
rc^nforthetheversionoftheright.^ 

Assuming that the time based conditions are satisfied, the server checks security and access conditions . step 
• «07 Such security and access conditions are satisfied if: 1 ) the requester is at the specified security class, or a higher 
M^unty class 2) the server satisfies any specified authorizatbn test and 3) the requester satisfies any specified au- 

PC ' Astuming that the security and access conditions are all satisfied, the server checks the copy count condition, 
stcp^SOB H the copy count equals zero, then the transaction cannot be completed and the transaction terminates per 

^^AsTuming that the copy count does not equal zero, the server checks if the copies in use for the requested right 
,s oreater Tan o equal to any copy count for the requested right (or relevant parts), step 1809. If the cop.es ,n use ,s 
HZ r than or eqSl to the copy'count, this indicates that usage rights for the version of the transact on have .been 
exhausted Accordingly, Ihe server terminates the transaction, step 1805. If the copy count .s less .than the copies .n 
use tor the transaction the transaction can continue, and the copies in use would be incremented by the number of 
dia.tal works requested in the transaction, step 1810. ... 

9 The seLLn checks if the digital work has a "Loan" access right, step 1811 . The "Loan" access nght .s a soeca 
case since remaining rights may be present even though all copies are loaned out. If the digital work has the Loan 
access r"h a check is made to see if all copies have been loaned out, step 1812. The number o cop.es that could 
be loaned is th sum of the Copy-Counts for all of the versions of the loan right of the digital work. For a composrte 
w;r«he rlvant figure the minimal such sum of each of the components of the composite work. If a I cop.es : have 

rights specifications from the versions of the Loan right. If there is only one version of the Loan nght, then ^ deter 
munition is simple. The remaining rights are the ones specified in that version of the Loan nght or none .f FUffnamn* 
Rights is not specified. If there are multiple versions of the Loan right and all cop.es of al of the versions ar loaned 
S then the remaining rights is taken as the minimum set (intersection) of rema.n.ng nghts »' ™™ 

of the loan right The server then determines if the requested right is in the set of rema.n.ng nghts, step 1814. If the 
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with the right, the server initiates End-Charge financial transacts to conf,rm billing, step 1819. 
Transmission Protocol 

An imoortant area to consider is the transmission of the digital work from the server to the requester. The trans- 
Knot s™ » hlec cS ,h, communication cnanno, can bo do,oo,od by ,h f in,og.«y chocks (e.g.. pan* 

Tatn^ 

10 ^^T^ the process o1 transmitting information during a transaction. Each 

box rSS^ J^^S^ in .tt her the server mode (above the central dotted line 1 901 ) or ,n the requester 

^VtC arTmore biocks tosend, the server warts until receding an Acknowledgement message from ^ 
WhJnlrknoSgement message is receded it sends the next b,ock to the requester and aga.n wa,ts for acknowl- 

wheleln VeTansaSfon is cancelled. Similarly, if the requester detects a commun.cat.ons fa.lure before rece^ng the 

> in stat 1 91 4 If the™ I a communications fai.ure before the server receives the final Acknowledge 

191 Mf the Zeter detects a communications failure at this state, it reports the fai.ure to its cred,t server ir . state 
1MB. buuti3mrts to the transaction. When it has committed, ft sends an acknowledgement message to the server. 
The server then enters its completion state 1919. 
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The key property is that both the server and the requester cancel a transaction if it is interrupted before all of the 
data blocks are delivered, and commits to it if all of the data blocks have been delivered. 

TheTe is a possibility that the server will have sent all of the data blocks (and commuted) but the requester will not 
have received all of them and will cancel the transaction. In this case, both repositories will presumably detect a com- 
mun,cations failure and report it to their credit server. This case wi.l probably be rare since it depends on "QMPncm 
tTming of the communications failure. The only consequence will be that the user at the requester repository may want 
t^equest a refund from the credit services - and the case for that refund wi.l be documented by reports by both 

'^^opivent loss of data, the server should not delete any transferred digital work until receiving the final acknowl- 
edgement from the requester. But it also should not use the file. A well known way to deal with this srtuation is called 

nW ^woThase n c^mmrtTo C ?k S as follows. The first phase works the same as the method described above. The server 
sends all of the data to the requester. Both reposrtories mark the transaction (and appropriate files) as umn^ 
The server sends a ready-to-commit message to the requester. The requester sends back an acknowledgement. The 
server then commits and sends the requester a commit message. When the requester receives the commrt message, 

" TlHere is e a communication failure or other crash, the requester must check back wrth the server to determine the 
status of the transaction. The server has the last word on this. The requester may have received all of the data, but if 
d d no get the final message, * has not committed. The server can go ahead and delete files (except for transact™ 
ecords) once it commrts, since the files are known to have been fully transmitted before starting the 2PC cycto 

There are variations known in the art which can be used to achieve the same effect. For example the server could 
use an additbnal level of encryption when transmitting a work to a client. Only after the client sends a memjeao- 
Lwledging receipt does it send the key. The client then agrees to pay for the digital work. The point of this variation 
is that it provides a clear audit trail that the client received the work. For trusted systems, however, this variation adds 
a level of encryption for no real gain in accountability. 

The transaction for specific usage rights are now discussed. 

The Copy Transaction 

A Copy transaction is a request to make one or more independent copies of the work with the same or lesser 
usage rights Copy drrfers from the extraction right discussed later in that it refers to entire digital works or entire folders 
containing digital works. A copy operation cannot be used to remove a portion of a digital work. 

. The requester sends the server a message to inrtiate the Copy Transaction. This message indi cates the > work to 
be copied, the version of the copy right to be used for the transaction, the destination address ,nformal.on (location 
in a folder) for placing the work, the file data for the work (including its size), and the number of cop.es requested. 

. The repositories perform the common opening transaction steps. 

. The server transmrts the requested contents and data to the client according to the transmission , prtfocol. If a 
Next-Set-Of-Rights has been provided in the version of the right, those rights are transmrtted I as the rights fo the 
work. Otherwise, the rights of the original are transmitted. In any event, the CopyOount f.eld for the copy of the 
digital work being sent right is set to the number-of-copies requested. 

. The requester records the work contents, data, and usage rights and stores the work. It records the date and time 
that the copy was made in the properties of the digital work. 

• The repositories perform the common closing transaction steps. 

The Transfer Transaction 

A Transfer transaction is a request to move copies of the work with the same or lesser usage rights to another 
repository. In contrast with a copy transaction, this results in removing the work copies from the server. 

. The requester sends the server a message to initiate the Transfer Transaction. This message indicates the work 
to be transferred, the version of the transfer right to be used in the transaction, the destination address information 
for placing the work, the file data for the work, and the number of copies involved. 

. The repositories perform the common opening transaction steps. 

. The seVver transmits the requested contents and data to the requester ^ ansm ^Z^°T h L 

a Next-Set-Of-Rights has been provided, those rights are transmitted as the rights for the work. Otherwise he 
rights of the original are transmrtted. In either case, the Copy-Count field for the transmitted rights are set to the 
number-of-copies requested. 
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. The requester records the work contents, data, and usage rights and ^ores work 

. The server decrements its copy count by the number of copies involved .n the transaction. 

. The repositories perform the common closing transaction steps. 

. if the number of copies remaining in the server is now zero, it erases the digital work from *s memory. 



The Loan Transaction 



A loan transaction is a mechanism for loaning copies of a digital work. The maximum duration of the loan is , de- 
termdd by anTnterna. parameter of the digital work. Works are automatically returned after a predetermined t,me 
period. 

. The reauester sends the server a message to initiate the Transfer Transaction. This message indicates the work 
I b 3e the version o, the loan right to be used in the transaction the ^f^^^T^ 
p°acL the work, the number of copies involved, the file data for the work, and the penod of the loan. 

. The server checks the validity of the requested loan period, and ends wrth an error f the penod is not va.-d. Loans 
for a loaned copy cannot extend beyond the period of the original loan to the server. 

. The repositories perform the common opening transaction steps. 

jt se^e Lsmits the requested contents and data to the requester. If a Next-Set-Of-Rights has been provided 
those rights are transmitted as the rights for the work. Otherwise, the rights of the original are transmitted, as 

. ^Ze^^S^or, contents, data, usage rights, and fcan period and stores the ^ 

. ™e servTupdates the usage rights information in the digital work to reflect the number of copies loaned out. 

f rom thetoan The user on "he requester p.atform can now use the transferred copies of the d.grtaT work. A user 
accessing the original repository cannot use the digital work , unless there are cop.es remam.ng. What happens 
next depends on the order of events in time. 

Casel. lf the timeof the loan period isnot yet exhausted and the requester sends the repository a Return message. 

. The return message includes the requester identification, and the transactbn ID. 

T^e server decrements the copies-in-use field by the number of copies that were returned. (I the number of 
SalTorks returned is greater than the number actually borrowed, this is treated as an error.) This step may 
now make the work available at the server for other users. 

. The requester deactivates its copies and removes the contents from its memory. 

case 2 , , f the time of the loan period is exhausted and the requester has not yet sent a Return message. 

. The server decrements the copies-in-use field by the number digital works that were borrowed. 

The requester automatically deactivates its copies of the digital work. It terminates a.l current uses and erases 
2 diglat work copies from memory. One question is why a requester would ever return a work, jartu* than 
he oeriod of the loan, since it would be returned automatically anyway. One reason for early return is that 
Inere may be a metered fee which determines the cost of the loan. Returning early may reduce that fee. 

The Play Transaction 

A olav transaction is a request to use the contents of a work. Typically, to "play" a work is to send the digital ^work 
throuah some kind of transducer, such as a speaker or a display device. The request impl.es the .mention that the 
contems^ 

on anv dioital medium, retained after the transaction or sent to another repository. 

TO. term W is natural for examples like playing music, playing a movie, or playing a video game^The genera, 
fnrm o n av means that a "player" is used to use the digital work. However, the term play covers all media and kinds 
LTrecordlng; ^Thus one woS W a digital work, meaning, to render it for reading, or play a computer program, 
meaning to execute it. For a digital ticket the player would be a digital ticket agent. 

. The reauester sends the server a message to initiate the play transaction. This message indicates the work to be 
^InTverSnrt the play right to be used in the transaction, the identity of the player being used, and the file 
data for the work. 
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. The server checks the validity of the player identification and the compatibility of the player identification with the 
player specification in the right. It ends with an error if these are not satisfactory. 

• The repositories perform the common opening transaction steps. 

. The se rver and requester read and write the blocks of data as requested by the player according to the transmiss.on 
protocol. The requester plays the work contents, using the player. 

• When the player is finished, the player and the requester remove the contents from their memory. 

• The repositories perform the common closing transaction steps 

The Print Transaction 

A Print transaction is a request to obtain the contents of a work for the purpose of rendering them on a 'printer." 
We use the term "printer" to include the common case of writing with ink on paper. However, the key aspect of 'printing" 
in our use of the term is that it makes a copy of the digital work in a place outside of the protection of usage rights. As 
with all rights, this may require particular authorization certificates. 

Once a digital work is printed, the publisher and user are bound by whatever copyright laws are in effect. However, 
printing moves the contents outside the control of repositories. For example, absent any other enforcement mecha- 
nisms once a digital work is printed on paper, it can be copied on ordinary photocopying machines wrthout intervention 
by a repository to collect usage fees. If the printer to a digital disk is permitted, then that digital copy is outside of the 
control of usage rights. Both the creator and the user know this, although the creator does not necessarily give tacit 
consent to such copying, which may violate copyright laws. 

. The requester sends the server a message to initiate a Print transaction. This message indicates the work to be 
played the identity of the printer being used, the file data for the work, and the number of copies in the request. 

. The se'rver checks the validity of the printer identification and the compatibility of the printer identification with the 
printer specification in the right. It ends with an error if these are not satisfactory. 

• The repositories perform the common opening transaction steps. 

• The server transmits blocks of data according to the transmission protocol. 

• The requester prints the work contents, using the printer. 

• When the printer is finished, the printer and the requester remove the contents from their memory. 

• The repositories perform the common closing transaction steps. 

The Backup Transaction 

A Backup transaction is a request to make a backup copy of a digital work, as a protection against media failure. 
In the context of repositories, secure backup copies differ from other copies in three ways: (1) they are made under 
the control of a Backup transaction rather than a Copy transaction, (2) they do not count as regular copies, and (3) 
they are not usable as regular copies. Generally, backup copies are encrypted. 

Although backup copies may be transferred or copied, depending on their assigned rights, the only way to make 
them useful for playing, printing or embedding is to restore them. 

The output of a Backup operation is both an encrypted data file that contains the contents and description of a 
work and a restoration file with an encryption key for restoring the encrypted contents. In many cases, the encrypted 
data file would have rights for "printing" it to a disk outside of the protection system, relying just on its encryption for 
security Such files could be stored anywhere that was physically safe and convenient. The restoration file would be 
held in the repository. This file is necessary for the restoration of a backup copy. It may have rights for transfer between 
repositories. 

. The requester sends the server a message to initiate a backup transaction. This message indicates the work to 
be backed up, the version of the backup right to be used in the transaction, the destination address information 
for placing the backup copy, the file data for the work. 

• The repositories perform the common opening transaction steps. 

. The server transmits the requested contents and data to the requester. If a Next-Set-Of-Rights has been provided, 
those rights are transmrtted as the rights for the work. Otherwise, a set of default rights for backup files of the 
original are transmitted by the server. 

. The requester records the work contents, data, and usage rights. It then creates a one-time key and encrypts the 
contents file. It saves the key information in a restoration file. 

• The repositories perform the common closing transaction steps. 

In some cases, it is convenient to be able to archive the large, encrypted contents file to secure offline storage, 
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tie (M not me description me) online in such a »ay that it can b. retrieved. 

5 

The Restore Transaction 

- Rca<i1orp transactio n is a request to convert an encrypted backup copy ot a digital work into a usable copy. A 
resto X" 
10 rights can include fees and access tests including authorization checks. 

* r «n* the server a message to initiate a Restore transaction. This message indicates the work to 

• £%Trr;.v^™ 

. . C-ZVlm^^L tile * available „.e. a d, 9 «a, wo* corresponding to the re qU es, has bean 
backed-up.) If it is not. it ends the transaction with an error. 
. The repositories perform the common opening transaction steps. 

th! ir^Pr retrieves the key from the restoration file. It decrypts the work contents, data, and usage r.ghts. 

of default rights for backup files of the original are transmrtted by the server. 
. The requester stores the digital work. 

• The repositories perform the common closing transaction steps. 
25 The Delete Transaction 

A Delete transactbn deletes a digital work or a number of copies of a digital work from a repository. Practically al. 
digital works would have delete rights. 
so . The requester sends the server a message to initiate a delete transaction. This message indicates the work to be 
deleted, the version of the delete right for the transaction. 
. The repositories perform the common opening transaction steps. 
. The server deletes the file, erasing it from the file system. 
. The repositories perform the common closing transaction steps. 

35 

The Directory Transaction 

45 are exercised as part of the normal process of exercising all r.ghts. 

. : mfsmmmms 

the transaction with an error. 
. The reDositories perform the common opening transaction steps. 

. Tne server sends the requested data to the requester according to the transm.ssion protocol. 
55 • The requester records the data. 

. The repositories perform the common closing transaction steps. 
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The Folder Transaction 

A Folder transaction is a request to create or rename a folder, or to move a work between folders. ^^fj\ 
Directory rights, Folder rights control the degree to which organization of a repos.tory can be accessed or modified 
from another repository. 

. The requester sends the server a message to initiate a Folder transaction. This message indicates the folder that 
is the root of the folder request, the version of the folder right for the transaction, an operation, and data The 
operation can be one of create, rename, and move file. The data are the specifications required for the operation, 
such as a specification of a folder or digital work and a name. 

. The repositories perform the common opening transaction steps. 

. The server performs the requested operation - creating a folder, renaming a folder, or moving a work between 
folders. 

. The repositories perform the common closing transaction steps. 
The Extract Transaction 

A extract transaction is a request to copy a part of a digital work and to create a new work containing it. The 
extraction operate differs from copying in that it can be used to separate a part of a digital work from d-b locks or 
sS That JLce additional restrictions or fees on it. The extraction operation differs from the edrt operation ,n that it 
does not change the contents of a work, only its embedding in d-blocks. Extraction creates a new d.grtal work. 

. The requester sends the server a message to initiate an Extract transaction. This message indicates the part of 
the wo* to be extracted, the version of the extract right to be used in the transaction, the destination address 
information for placing the part as a new work, the file data for the work, and the number of cop.es involved. 

• The repositories perform the common opening transaction steps. 

. The server transmits the requested contents and data to the requester according to the transmission protocoUf 
a Next-Set-Of-Rights has been provided, those rights are transmftted as the nghts for the new work. Otherw.se. 
fherightsoftheoSginai are transmitted. The Copy-Count field for this rightissettothenumber^o^ 

. The requester records the contents, data, and usage rights and stores the work. It records the date and t,me that 
new work was made in the properties of the work. 

• The repositories perform the common closing transaction steps. 

The Embed Transaction 

An embed transaction is a request to make a digital work become a part of another digital work or to add a shell 
d-block to enable the adding of fees by a distributor of the work. 

. The requester sends the server a message to initiate an Embed transaction. This message indicates the work to 
be embedded, the version of the embed right to be used in the transaction, the destination address information 
for Dlacinq the part as a a work, the file data for the work, and the number of cop.es involved. 

. The Le-er checks the control specifications for all of the rights in the part and the destination. If they are ,ncom- 
patible, the server ends the transaction with an error. 

. The repositories perform the common opening transaction steps. 

. The server transmits the requested contents and data to the requester according to the transm.ss.on FotoooUf 
a Next-Set-Of-Rights has been provided, those rights are transmitted as the rights for the new work. Otherw se. 
th ^rightsoftheoriginalaretransmitted. The Copy-Count field for this rights set to the number^op.es requested. 

. The requester records the contents, data, and usage rights and embeds the work m the destination file. 

. The repositories perform the common closing transaction steps. 

The Edit Transaction 

An Edit transaction is a request to make a new digital work by copying, selecting and modifying portions of an 
existtg digital work. This operation can actually change the contents of a digital work. The kinds of changes that are 
permitted depend on the process being used. Like the extraction operation, edit operates on portions of a d.grtal wo k. 
E 'contest wrth the extract operation, edit does not affect the rights or location of the work. It only changes the con ents. 
T^^^nges permitted are determined by the type specification of the processor specified ,n the nghts. In the 
currently preferred embodiment, an edit transaction changes the work itself and does not make a new work. However, 
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it would be a reasonable variation to cause a new copy of the work to be made. 

nrocess-ID for the process, and the number of copies involved. 
. The se Jer checks the compatibility of the process-ID to be used by the requester aga.nst any process-.D spec 

fication in the right. If they are incompatible, It ends the transaction with an error. 
. The repositories perform the common opening transaction steps. evamn , P » can se |ect 

rZ Pnuester uses the process to change the contents of the digital work as des.red. (For examp e, it can select 

. The repositories perform the common closing transaction steps. 



Tho oHit transac tion is used to cover a wide range of kinds of works. The category describes a process that takes 

3 i- nr of-trlinn reverberations. 



ess?? *» ~ - ^ - •* m nM chan9ing oi me ,oni '" y 

Authorization Transactions 

There are many ways that authorization transactions can be defined. I n the following, our preferred way is to .simply 

speak ol '^^STatton-ID. emich identities an aulhorization object (a digital »ork ,n a Me of a 

«JaZS -ve and »hich . must process. ™e authorization is gtuen ,o ,ha generic 

sa™ o* ™y M a^otha, server. When a remote authorization eerver ie retired, it must eonta.n a drgrta, addreee. 
" T.ISS 2ESZ»°2!£t reguired. then the authorization pr<*ess are, performs the tolling steps: 
. The generic authorization serve, attempts to set up the communications channel. (II the channel cannot be ee, 
. ^Selen^^ 

signaling that authorization is granted. 
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The Install Transaction 

An Install transaction is a request to install a digital work as runnable software on a repository. In a typical caw. 
the rtquesX repository is a rendering repository and the software would be a new k,nd or new version of player. 
A.L!n a typicatcase, fte software would be copied to file system of the requester repository before rt .s .nstalled. 

. The requester sends the server an Install message. This message indicates the work to be installed, the version 

of the Install right being invoked, and the file data for the work (including its s.ze). 
. The repositories perform the common opening transaction steps. 

. jZ requester tracts a copy of the digital certificate for the software. If the certrf.cate cannot be found or the 
master repository for the certrficate is not known to the requester, the transacts ends w,th an error 

. The requester decrypts the digrial certrficate using the public key of the master repository, recording the ,den *y 
If the supplier and creator, a key for decrypting the software, the compatibility information, and a tamper^heckmg 

. Tr^*:"~^ the key from the certrficate and computes a check code on « using a 
! way nash function If the check-code does not match the tamper-checking code from the certrficate the unstal- 
IZr ^ansac tbn ends with an error. (This step assures that the contents of the software, including the vanous 

lompaTb^ with the repository, the installation transaction ends with an error. (Th.s step checks platform compat- 

. Sequester retrieves the instructions in the installation script and follows them. If there is an error in this process 
Luch as Sufficient resources), then the transaction ends with an error. Note that the mstallat.on process puts the 
unnable so^wa S place in the repository where it is no .onger accessible as a work for exercis.ng any usage 
W ^ ofher mTnthe execution of thesoftware as part of repository operations in carrying out other transacts, 

. The repositories perform the common closing transaction steps. 

The Uninstall Transaction 

An Uninstall transaction is a request to remove software from a repository. Since uncontrolled or incorrect removal 
of software from a repository could compromise its behavioral integrity, this step .s controlled. 

. The requester sends the server an Uninstall message. This message indicates the work to be uninstaller the 
version of the Uninstall right being invoked, and the file data for the work (including its size). 

. The repositories perform the common opening transaction steps. 

. The requester extracts a copy of the digital certrficate for the software. If the certrficate cannot be found or the 
master repository for the certrficate is not known to the requester, the transaction ends with an error. 

. TUe Z^esTZcte whether the software is instal.ed. If the software is not installed, the transact™ ends wrth 

. ThTrequester decrypts the digrta. certificate using the public key of the master reposrfory, fording the identity 
If the supplier and creator, a key for decrypting the software, the compatibility mformat.on and a tamper*heck,ng 
code mE step authenticates the certification of the software, including the scr.pt for un.nsta ling rt.) 

. Tht requester decrypts the software using the key from the certificate and computes a check cod e on*u.rja 
Iwav ^Sash function If the check-code does not match the tamper^hecking code from the certrf icate the Mnstal- 
IZ ftransaciion ends with an error. (This step assures that the contents of the software, inc.udmg the vanous 

. in the uninsta.lation script and follows them. If there is an error in this 

process (such as insufficient resources), then the transaction ends with an error. 
. The repositories perform the common closing transaction steps. 

Claims 

1 A system for controlling the distribution and use of digital works having a mechanism for reporting fees based on 
the distribution and use of digital works, said system comprising: 

means for attaching usage rights to a digital work, each of said usage rights specifying how a d j9^rk may 
be used or distributed, each of said usage rights specifying usage fee informat.on, sa,d usage fee ,nformat,on 
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comprising a fee type and fee parameters which define a fee to be paid in connection with the exercise of said 
"communication medium for coupling repositories to enable communication between repositories; and 
a plurality of repositories, each of said repositories comprising, 
an external interface for removably coupling to sad communications medium; 

^Tngld to . Lording lee transact from said .eposto-y and aabsaquan.ly rapomng ea,d tea transacts 
to a billing clearinghouse. 

The fee reporting system as recited in Claim 1 wherein said fee type of said fee information is a metered use fee, 
a per use fee. a best price fee, a scheduled fee.or a mark-up fee. 

A method for reporting fees associated with the distribution and use of digital works in a system for controlling the 

distribution and use of digital works, said method comprising the steps of: 

a\ attachinq one or more usage rights to a digital work, each of said one or more usage rights comprising , an 
M%£ To* rsaiS digital work may be distributed or used and a usage fee to be P a,d upon exercise of said 

^storing said digital work and attached one or more usage rights in a server repository, said server repository 
cTSs^r^ 

d said server repository identifying a usage right associated with sa,d access request, 

e) said server repository determining if said identified usage right is the same as one of said one or more 

accnriatpd with the exercise of said usage right, 

h " u age ee is associated with usage right, said server repository calculating said usage fee 

i) safd server reposrtory transmitting a first assign fee transaction identrfymg said request.ng repos.tory as a 

as a payer for said usage fee to a second credit server; 

k) said server repositoiy transmitting said digital work to said requesting repos.tory 

;„d=;^a^^ 

lor each of the plurality of independent digital works. 

A method for reporting fees associated with the distribution and use of digital works in a system for contro.ling the 
distribution and use of digital works, said method comprising the steps of: 

a) attachinq one or more usage rights to a digital work, each of said one or more usage rights comprising an 
Tnd^aS 

b) S 'saSTgifcl work and said attached one or more usage rights in a server reposrtory. sa,d server 
rpnositorv controllinq access to said digital work; 

X servT reposrtory receiving a request to access said digital work from a request. ng repository, 
d said server reposrtory identifying a usage right associated with said access request 
2 said IZer reposrtoy determining if said digital work has attached thereto sa.d .dentrf.ed usage right 
? TsaidTn i fed'sage right is no? attached to said digital work, said server repository denymg access to 
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^2 said^sTge' right is attached to said digital work, said server repository determining if a usage fee is 
associated with the exercise of said usage right; 

h> if a usage fee is associated with said usage right, said server repository determining a lee type; 
i) said server repository transmitting a first fee transaction identifying said requesting repository as a payee 
for said usage fee to a credit server, said first fee transaction being dependent on said determined fee type; and 
k) said server repository transmitting said digital work to said requesting repository. 

6. A system for controlling the distribution and utilization of digital works having a mechanism for reporting usage 
fees, said system comprising: 

digrtal works comprising a first part for storing the digitally encoded data corresponding to a digital work and 
a second part for storing usage rights and fees for said digital work, said usage rights specify.ng how a dig tal 
work may be used or distributed and said usage fees specifying a fee to be paid m connect.on with the exerc.se 
of a corresponding usage right; 

a plurality of repositories, each of said repositories comprising: 

communication means for communicating with another of said plurality of repositories; 
storaqe means for storing digital works; 

requesting means for generating a request to access a digital work stored in another of said plurality of repos- 
itories, said request indicating a particular usage right; 

processing means for processing requests to access digital works stored in said storage 

access when sad particular usage right corresponds to a stored usage nght stored in said d.gital work said 

processing means generating fee transactions when said access is granted and said stored usage right spec- 

ea^ofsaid plurality of repositories being removably coupled to a credit server, said credit server being 
arranged for recording fee transactions from said reposrtory and subsequently reporting said fee transactions 
to a billing clearinghouse. 

7 The system as recited in Claim 6 wherein said storage means is further comprised of a first storage device for 
stor^ 

8 A method for reporting fees associated with use of rendering digital works by a rendering device in a system for 
SI rendering of digital works by a rendering system, said rendering system comprised of a rendering 
^ository and a rendering device, said rendering device utilizing a rendering digital work for rendering a digrtal 
work, said method comprising the steps of: 

a) storing a first digital work in a server repository, said digital work specifying a first usage fee to be reported 
for a use of said first digital work; 

b) storing a rendering digital work in said rendering repository, said first rendering digrtal work specfy.ng a 
second usage fee to be reported for a use of said rendering digrtal work; 

c) said server repository receiving a request to use said first digital work from said rendering reposrtory; 

d) said server reposrtory determining if said request may be granted; 

e) if said server repository determines that said request may not be granted, said server repository deny.ng 
access to said first digital work; 

f) if said server repository determines that said request may be granted, sari server reposrtory transmrtt.ng 
said digital work to said rendering repository; 

g) said server reposrtory transmitting a first fee transaction identifying said rendering repository as a payee 
for said first usage fee for use of said first digital work to a first credit server; 

h) said rendering device rendering said first digital work using said rendering digital work; and 

h said rendering repository transmitting a second fee transaction identifying said rendenng reposrtory as a 
payee for said second usage fee for use of said rendering digital work to a second credrt server. 

9 The method as recited in Claim 8 further comprising the step of said rendering repository tr^smMing a third fee 
transaction identifying said rendering repository as a payee for said first usage fee for use of said first d.grtal work 
to said second credit server. 

10. The method as recited in Claim 9 wherein said rendering digital work is a set of coded rendering instructions for 
controlling said rendering device. 
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1 501 — Digital Work Rights: = ■ Rights*) 

1502 — Right : = (Right-Code {Copy-Count} {Control-Spec} {Time-Spec } 

{Access-Spec} {Fee-Spec}) 
7503 — Right-Code : = tender-Code I Transport-Code | File-Management- 
Code! Derivative-Works- Code | Configuration-Code 
7504 —Render-Code : = [ Play : {Player: Player-ID} I Print: {Printer: Pnnter-ID}] 

7505— Transport-Code := [Copy | Transfer | Loan {Remaining-Rights: 
Next-Set-of-Rights}]{(Next-Copy-Rights:Next-Set-of-R.ghts)} 

7506— File-Management-Code := Backup {Back-Up-Copy-Rights: 

Next-Set-of-Rights} | Restore | Delete | Folder 
| Directory {Name: Hide-Local | Hide-Remote} 
{Parts: Hide-Local | Hide-Remote} 

7507— Derivative- Works-Code : = [Extract | Embed | Edit{Process: 

Process-ID}} {Next-Copy-Rights : 
Next-Set-of Rights} 
750S — Configu ration-Code : = Install | Uninstall 
7 509 -Next-Set-of-Rights : = {(Add: Set-Of-Rights)} {(Delete: 

Set-Of-Rights)} {(Replace: Set-Of-Rights )H(Keep: Set-Of-Rights )} 
7570— Copy-Count : = (Copies:positive-integer 1 0 1 Unlimited) 
7 57 7 —Control-Spec : = (Control: {Resectable | Unresectable} 

{Unchargeable | Chargeable}) 
7572— Time-Spec := ({Fixed-Interval | Sliding-Interval | Meter-Time} 
Until: Expiration-Date) 
7573— Fixed-Interval := From: Start-Time 
1514 — Sliding-Interval : = Interval: Use-Duration 
7575— Meter-Time: = Time-Remaining: Remaining-Use 
7 576— Access-Spec : = <{SC: Security-Class} {Authorization: Authorization- ID } 

{Other-Authorization: Authorization-ID*} (Ticket: Ticket-ID}) 
7 57 7— Fee-Spec: = {Scheduled-Discount} Regular-Fee-Spec | Scheduled-Fee-Spec | 
Markup-Spec 

7575- Scheduled-Discount" Scheduled-Discount: (Scheduled-Discount: 

(Time-Spec Percentage)*) 
7579— Regular.Fee-Spec:=({Fee:|Incentive:}[Per-U 9 e-SpeclMetered-Rate- 
Spec | Best-Price-Spec | Call-For-Price-Specl 
{Min: Money-Unit Per: Time-Spec}{Max: 
Money-Unit Per: Time-Spec} To: Account-ID) 
7520 — Per-Use-Spec:= Per-Use: Money-unit 

7527 — Metered-Rate-Spec : = Metered: Money-Unit Per: Time-Spec 
7522— Best-Price-Spec : = Best-Price: Money-unit Max: Money-unit 
J523 — Call-For-Price-Spec := Call-For -Price 
7 524 — Scheduled-Fee-Spec: = (Schedule: (Time-Spec Regular-Fee-Spec)* ) 
7525— Markup-Spec: = Markup: percentage To: Account-ID 

F/g.75 
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